Code review

Nice fix — the pre-fetch pattern is the right call for avoiding permission prompt spam. Two things I want to clarify:

1. Agent type switch: The command now uses feature-dev:code-reviewer instead of zforge:code-reviewer, which means our agent definition (agents/code-reviewer.md) with the confidence scoring and output format won't be picked up automatically. Was this intentional? If so we'd be duplicating those instructions inline and they'll drift over time. Let's chat about whether we can keep using zforge:code-reviewer with just the tools stripped.

2. Agent definition now assumes inline data: The History & Context section was updated to say "Analyze the provided git blame/log output" and "do not run git commands yourself" — but the agent still has Glob, Grep, Read as tools and could be spawned standalone outside of /review. In that case nobody would be providing inline data. Might be worth keeping the original wording or adding a conditional ("If data is provided inline, use that; otherwise run the commands yourself").

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

Hey! Great catch on the permission prompt spam — this was a real usability pain point.

We went with a different approach on main (ea782ca) that builds on the same insight but takes it further: instead of making reviewers pure text analyzers, we rewrote /review to use the spawn/monitor pattern (same one that powers /feature-orchestrate).

What changed

Each reviewer now runs as an independent claude -p process with its own --allowedTools, so they can freely use Read, Glob, Grep, and Bash without any permission prompts. This matters because zforge reviews often cover large multi-phase features where inline pre-fetching would blow up the orchestrator's context window.

We also added:

• --only flag for selective reviewer execution (e.g. --only simplicity,bugs) — useful when you just need a quick focused review instead of the full 4-reviewer suite
• Sentinel files + orphan detection so the monitor can track reviewers even if they die before writing output
• spawn-codex.sh as a separate spawner for Codex CLI agents (different flags/format than claude)
• Fixed spawn-agent.sh to unset CLAUDECODE so nested spawning works

Why not the pure text analyzer approach?

It works well for small diffs, but zforge's primary use case is reviewing entire feature implementations (5-15+ files). Pre-fetching all that content into the orchestrator and passing it inline would consume too much context. Letting reviewers use their own tools keeps the orchestrator lightweight and lets each reviewer explore the codebase independently.

The agent definition (code-reviewer.md) stays unchanged with its tools — this way it remains usable standalone if needed, and the command references it as the single source of truth for focus areas and scoring rubrics.

Thanks for surfacing this issue — it pushed us to a much better architecture!